LGTM given that the scope is limited to deferred loading of in-tree drivers, but this has limited utility in the scope of rfc85 where we try to keep large/external/proprietary drivers out of tree

I'm wondering if it would be possible to obtain the same outcome with completely out-of-tree drivers, using some kind of code-generation at cmake time:

• cmake accepts -DADD_DEFERRED_PLUGIN_FOO=/path/to/foodriver/core.cpp with core.cpp containing the well-known functions FOODatasetIdentify, FOODriverSetCommonMetadata and DeclareDeferredFOOPlugin (in the same way that for traditional plugins we expect a gdal_foo.so file to contain a GDALRegister_foo() function)
• add the /path/to/foodriver/core.cpp to the list of files to be compiled into the main libgdal.so library
• use code generation to create the DeclareDeferredPlugins() function that will be called by GDALAllRegister():

// this file is automatically generated and will be overwritten, do not edit manually
void DeclareDeferredPlugins() {
  DeclareDeferredFOOPlugin(); //from -DADD_DEFERRED_PLUGIN_FOO
  DeclareDeferredBARPlugin(); //from -DADD_DEFERRED_PLUGIN_BAR
}

I'm wondering if it would be possible to obtain the same outcome with completely out-of-tree drivers

good point. Turns out to be quite straightforward. I've added a new commit in the RFC with that capability and candidate implementation in rouault@7f9c686

Candidate implementation available in #8695